Misuse and Abuse Cases: Getting Past the Positive

trend, most systems for designing software also tend to describe positive features. Savvy software practitioners are beginning to think beyond features, touching on emergent properties of software systems such as reliability, security , and performance. This is mostly because experienced customers are beginning to demand secure and reliable software; but in many situations, it's still up to the software developer to define " secure " and " reliable. " To create secure and reliable software , we first must anticipate abnormal behavior. We don't normally describe non-normative behavior in use cases, nor do we describe it with UML, but we must have some way to talk about and prepare for it. " Misuse " (or " abuse ") cases can help organizations begin to see their software in the same light that attackers do. By thinking beyond normative features, while simultaneously contemplating negative or unexpected events, software security professionals can better understand how to create secure and reliable software. Guttorm Sindre and Andreas Opdahl extend use-case diagrams with misuse cases to represent the actions that systems should prevent in tandem with those that they should support for security and privacy requirement analysis. 1 Ian Alexander advocates using misuse and use cases together to conduct threat and hazard analysis during requirements analysis. 2 In this article, we provide a non-academic introduction to the software security best practice of misuse and abuse cases, showing you how to put the basic science to work. In case you're keeping track, Figure 1 shows you where we are in our series of articles about software security's place in the software development life cycle. Security is not a set of features There is no convenient security pull-down menu that will let you select " security " and then sit back and watch magic things happen. Unfortunately , many software developers simply link functional security features and mechanisms somewhere into their software, mistakenly assuming that doing so addresses security needs throughout the system. Too often, product literature makes broad, feature-based claims about security, such as " built with SSL " or " 128-bit encryption included, " which represent the vendor's entire approach for securing its product. Security is an emergent property of a system, not a feature. This is like how " being dry " is an emergent property of being inside a tent in the rain. The tent only keeps you dry if the poles are …